Dl-S  FILE  COPY 


CsJ 

O) 

O) 

Csl 

CM 

< 

I 

O 

< 


Report  No.  71o5 


Monitorinii  CAPS  and  SURAP  Networks  (SRNTN-12) 


Michael  Cote 


Prepared  By; 


BBN  Systems  and  Technologies  Corporation 
10  Moulton  Street 
Cambridge.  MA  02138 

Prepared  for: 

DARPA/ISTO 
1400  Wilson  Bl. 

Arlington.  VA.  22209 

Sponsored  by: 

The  Defense  Advanced  Research  Projects  Agency 
Under  Contract  No.  MDA-903-83-C-0173 


The  views  and  conclusions  contained  in  this  document  are  those  of  the  authors  and  do  not  represent  the 
official  policies,  either  expressed  or  implied,  of  the  Defense  Advanced  Research  Projects  Agency,  the 
Army  or  the  United  States  Government. 


Report  No.  7165 


BBN  Systems  and  Technologies  Corporation 


Contents 


1  Introduction  and  Summary 

1.1  NetMan  Considerations 


2  Monitoring  Data  and  Its  Uses  3 

3  THE  MDP  PROTOCOL  5 

’.1  Justitication  .  .  .  5 

3,2  MDP  Header .  5 

3  3  MDP  Sessions .  5 

3  4  Session  Aborts  b 

3.5  LPR  algorithms  o 


.4.  MDP  Packet  Formats  8 

.A..1  The  MDP  Pac'  '  Header .  .  9 

•A.l  MDP  Type  #  0  -  Rac  rlequest/Cottimand  Packet .  10 

.\.2  MDP  Type  #1  -  General  Status .  .  13 

A.3  MDP  Type  #  2  -  Routing  Information  .  19 

A.4  MDP  Type  #  3  -  CUMsW  Values .  20 

\.5  MDP  Type  #  4  -  Neighbor  LPR  Data .  22 

A.6  MDP  Type  #  5  -  LPR  Module  Versions  .  26 

A.  7  MDP  Type  #  6  -  LPR  Fault  Queue .  27 

A.8  MDP  Type  #  7  -  LPR  Timer  Values  .  28 

A.9  MDP  Type  #  8  -  LPR  Command  NACK .  29 


B  MDP  Triggers 

C  .Algorithms  for  Packet-Length  Statistics 


BBN  Systems  and  Technologies  Corporation 


Report  No.  7165 


1.  Introduction  and  Summary 


Network  monitoring  is  necessary  for  debugging  protocols,  measuring  network  performance,  determining 
routes,  and  predicting  network  functionality.  These  tasks  require  data  collection.  Network  Monitoring 
systems  must  poll  Low-Cost  Packet  Radios  (LPRs)  for  specific  types  of  data,  then  process  it  for  an 
operator.  The  Monitoring  Data  Packets  (MDPsi  specified  in  this  document  provide  a  flexible  mechanism 
for  momtonng  systems  to  collect  this  data  from  an  LPR  network.  Specific  SURAP  network  monitoring 
applications  that  require  MDPs  are;  Siting  .A.ids  for  deploymg  the  LPRs,  NetMan  for  global  network 
management,  and  the  NIU  (.Network  Intert'ace  Uniti  for  local  network  information. 

This  document  specifies  the  MDP  formats  for  SURAPl  and  SURAP2.  These  formats  (see  Appendix 
.A)  are  the  result  of  merging  the  packet  radio  PDP  (Performance  Data  Packet!  and  the  DIP  (Device 
Int'ormation  Packet).  The  remamder  of  the  data  is  derived  from  the  C.\P  LROP  and  from  inlbrmation 
which,  in  the  CAPS  networks,  has  been  available  only  from  the  PR  itself  using  the  XRAY  tool. 

1.1  Net. Man  Considerations 

The  following  section  is  a  brief  overview  of  the  SURAP  NetMan.  For  a  more  detailed  description  of  the 
vanous  services  that  the  NetMan  will  provide,  refer  to  SRNTN  26.  For  the  techmcal  design  of  NetMan. 
refer  to  SRNTN  10. 
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2.  Monitoring  Data  and  Its  Uses 

The  data  that  we  gather  allows  NetMan  to  provide  the  operator  with  the  following  four  basic  services; 

•  views  of  the  current  network  state  -  visual  depictions  derived  from  the  currently  available  network 
data  which  has  been  reduced  to  a  form  more  easily  interpreted  by  the  operator. 

•  alerts  to  critical  network  events  —  pointers  to  possible  problems  in  network  behavior  to  allow  tor 
isperator  follow-up 

•  tools  to  load  SCRAP  software 

•  tools  to  tune  and  debug  the  network. 

To  display  the  connectivity,  traffic  flows,  and  routes  in  a  parucular  area,  the  Network  .Manager  needs 
to  gather  data  in  the  following  categories; 

•  component  connectivity  (PR.  CH,  SCHI 

•  component  membership  (PRs  in  a  cluster,  etc.) 

•  traffic  on  logical  or  physical  links 

•  available  services  -  network  interface  units,  node  trackers,  etc. 

•  status  of  components 

( up/down/  flaky/ saturated/re  liable/. . .) 

•  fault  reports. 

The  Network  Manager  reduces  the  large  amount  of  data  produced  by  the  various  reporting  network 
components  mto  views  which  the  operator  can  easily  interpret  and  act  upon. 
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The  Network  Manager  design  paper,  SRNTN  10.  lists  nine  problems  which  arise  in  C.AP8  and  SURA? 
radio  networks.  The  Network  Manager  must  be  able  to  display  the  data  it  has  gathered  in  a  way  that 
allows  the  operator  to  notice  if  one  of  these  situations  has  occurred.  The  problems  listed  include; 

1 .  packet  radio/cluster  head  failure/maiiunction 

2.  e.\cessive  traffic  forwarding  in  a  cluster 

3.  excessive  control  traffic  in  a  cluster 

4.  labeling/clustering  instability 

5.  failure  to  find  a  route 

n.  failure  to  find  a  device 

route/link  failure/fluciuation 

S.  link/packct  radio  saturation 

network  resource  hogging  by  a  packet  radio  host. 

Ongoing  research  and  continued  evolution  of  the  Network  Manager  is  uncovenng  additional  areas  m 
which  debugging  aids  can  be  provided.  These  areas  include: 

1 .  finding  bugs  and  inefficiencies  in  network  algorithms 

2.  verifying  that  these  algorithms  are  correctly  implemented 

3.  validating  the  algorithm  designs 

4.  facilitatmg  the  control  of  network  components 

5.  analyzing  performance 

6.  supporting  administrative  needs 

7.  isolating  faults. 

The  Network  Manager  must  be  able  to  display  a  spectrum  of  views  ranging  from  coarse  to  fine,  terse 
to  verbose.  The  operator  can  use  these  views  to  focus  on  the  relevant  data  and  to  narrr  *  down  the 
possible  causes  of  the  problem.  These  views  are  mtended  to  help  the  operator  examme  the  three  network 
attributes  mentioned  earlier  —  connectivity,  traffic  flows,  and  routes  ....  and  to  allow  the  operator  as 
much  flexibility  as  possible  to  aid  the  opieracor  in  debugging  problems  in  the  network  and  in  testmg 
network  reactions  to  various  operations. 
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3.  THE  MDP  PROTOCOL 

3.1  Justification 

Because  MDPs  use  SNAP  as  the  transport  protocol,  which  does  not  allow  for  multi-packet  messages 
umd  therefore  allows  for  no  message  fragmentation  or  reconstruction),  a  simple  MDP  protocol  has  been 
created.  Other  aspects  of  the  MDP  protocol  deal  with  requesting  MDPs  from  LPRs  and  with  the  LPRs 
responses  to  these  requests. 

3.2  MDP  Header 

The  MDP.  header  serves  three  functions.  First,  it  allows  a  monitor  to  parse  the  te.xt  of  the  MDP.  Second. 
It  timestamps  the  message.  Third,  it  provides  packet  sequencing  in  a  multi-packet  MDP  message. 

The  version  number  is  used  to  differentiate  between  protocol  versions.  As  new  protocols  are  devel¬ 
oped.  the  version  numbers  are  incremented.  When  a  monitor  receives  an  .MDP  packet  with  the  wrong 
version  number  it  can  prevent  itself  from  incoirectly  parsing  the  packet. 

The  MDP  (message)  type  field  is  used  to  determine  which  ot  the  packet  text  formats  to  use  to  parse 
the  .MDP  text.  Up  to  64  types  are'currently  allowed. 

The  PR  Timestamp  field  is  a  32-bit  segment  of  the  LPR  protocol  clock  s  -t8-bit  number.  The  least 
sigmhcant  eight  bits  and  the  most  significant  eight  bits  are  masked  off.  Because  the  LPR's  protocol  clock 
has  units  of  26  milliseconds,  the  units  of  the  MDP  timestamp  are  6.656  milliseconds  (26  milliseconds  • 
256  [256  =  2**]).  Because  the  timestamp  has  32  bits,  it  will  not  wrap  around  for  over  330  days. 

For  message  sequencing,  two  fields  are  used,  pkt  number  and  #  of  pkts.  The  first  is  the  position 
of  this  packet  in  the  message,  the  second  is  the  total  number  of  packets  in  a  message.  A  one-packet 
message  would  have  1,1  respectively.  Packet  2  of  a  five-packet  message  would  have  2.5  respectively. 

3.3  MDP  .Sessions 

To  start  an  MDP  session,  a  monitor  transmits  a  Radio  Command/Request  Packet  (RRCP  -  MDP  Type  #0) 
to  the  LPR.  This  packet  is  used  to  request  the  non-event-driven  MDPs  2  through  7,  to  make  a  one-time 
request  of  MDP  #1,  or  to  request  MDP  #1  on  an  event-driver  basis.  It  is  also  used  to  modify  the  tnggers 
for  MDP  #1  transmission,  or  to  clear  cumulative  statistics,  also  known  as  CUMSTATs. 

The  RRC2P  header  contains  a  version  and  command  type.  To  request  MDP  message  types  2  or 
to  make  a  one-time  request  of  MDP  #1.  the  momtor  sets  the  sub_type  field  to  SEND_MDP  and  scls 
the  MDP  type  to  the  number  corresponding  to  the  packet  type  desired.  The  monitor  should  receive 
one  message  in  response  to  this  request  However,  if  the  LPR  is  currently  servicing  a  request  for  some 
other  monitor,  the  MDP  request  will  be  dropped  (but  SNAP  ACKed)  and  the  monitor  will  receive  Radio 
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Command  NAK  Packet  iRCNP  -  VIDP  Type  #8)  in  response;  the  monitor  must  retransmit  the  request  at 
a  later  time. 

To  request  MDP  #l  on  an  event-driven  basis,  the  monitor  sets  the  sub_type  field  to  SEND_.VIE_MDP1. 
Optionally,  the  monitor  can  set  the  minimum  and  maximum  timers  for  the  MDP  #1  timeouts  (within  cer¬ 
tain  constraints).  The  minimum  timer  sets  the  minimum  number  of  seconds  which  must  elapse  between 
.VIDP  #1  transmissions.  However,  the  LPR  will  enforce  a  thirty-second  minimum.  The  maximum  timer 
sets  the  maximum  number  of  seconds  between  transmissions.  The  last  SEND_ME_1VIDP1  which  spec¬ 
ifies  the  minimum/maximum  timers  will  determme  the  value  of  these  timers  in  the  LPR.  Values  of  zero 
for  either  the  muumum  or  ma.ximum  timers  will  result  in  the  current  timer  values  remaining  unchanged. 
The  default  value  for  the  minimum  timer  is  thirty  seconds;  for  the  maximum  timer,  the  value  is  thirty 
minutes  ( 1800  seconds). 

As  the  tnggers  occur  in  the  LPR.  the  monitor  will  receive  MDP  #1  packets.  To  request  a  certain 
trigger,  the  monitor  must  set  the  bit  corresponding  to  this  trigger  in  the  trigger  mask  field.  If  the  LPR 
acknowledges  the  request  but  an  .VIDP  #1  packet  has  just  been  transmitted  to  some  other  monitor,  the  LPR 
Oil  11  wait  the  minimum  mter-transmission  time  before  transmitting  another  .MDP  #l  packet.  Otherwise, 
if  it  acknowledges  the  request,  it  will  transmit  the  MDP  #l  packet  immediately.  If  the  LPR  “NAK”s  the 
request,  the  monitor  will  receive  an  RCNP  with  the  “NAK  reason”  set  to  C.\NT-SET_VIDP_DEST.  and 
the  list  of  monrtors  which  are  already  monitoring  the  LPR. 

To  cancel  event-driven  MDP  #1  packet  transmissions,  the  monitor  sends  a  CANCEL_MDP1  request. 
Successful  transmission  li.e..  receiving  the  SNAP  ACK)  implicitly  acknowledges  this  packet. 

To  clear  the  CUMSTATs.  the  monitor  sets  the  sub_type  field  to  CLEAR_CL^IST.\T  and  sets  the 
te.\t  to  a  48-bit  number  corresponding  to  the  time  (in  6.656  millisecond  units)  at  which  the  LPR  should 
clear  the  cumulative  statistics.  This  48-bit  number  is  relative  to  the  timestamp  which  the  LPR  has  returned 
in  the  MDP  header.  A  value  of  zero  indicates  that  the  LPR  must  clear  the  cumulative  statistics  upon 
receiving  the  packet. 

3.4  .Ses.sion  Aborts 

If  a  monitor  has  requested  an  MDP  message  and  knows  (since  it  has  received  the  first  packet  of  the 
message)  that  the  message  is  a  multi-packet  message,  the  monitor  should  abort  if  the  next  packet  does 
not  amve  promptly.  However,  since  the  LPR  may  miss  some  of  the  acknowledgements  from  the  SNAP 
transport  and  therefore  retransmit,  two  SNAP  timeout  periods  should  be  the  minimum  timeout:  one  for 
the  packet  just  received  and  one  for  the  next  packet  in  the  sequence.  This  ensures  that  messages  will  not 
be  aborted  needlessly. 

3J  LPR  algorithms 

The  LPR  must  maintain  a  list  of  monitors  and  their  corresponding  trigger  masks.  In  addition,  the  LPR 
requires  miiumnm  and  maximum  timers,  a  global  trigger  mask  (in  which  to  collect  the  outstanding 
triggers),  and  a  “snap-shot”  buffer  to  maintain  a  copy  of  an  MDP  for  either  multi-destination  or  multi¬ 
packet  transmission.  After  SURAP  protocol  startup,  the  LPR  will  clear  the  monitoring  list;  it  will  transmit 
no  MDPs  on  an  event-driven  basis  until  it  receives  a  request  to  do  so. 
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As  the  tnggers  occur  in  the  LPR.  they  are  collected  in  the  global  trigger  mask  until  an  MDP  #l  packet 
transmission  is  agam  allowed;  the  time  between  MDP  #l  transmissions  cannot  be  less  than  the  minimum 
inter-transmission  hme.  Each  time  the  maximum  inter-transmission  time  elapses,  the  LPR  will  send  an 
MDP  #l  packet  to  all  monitors  that  have  set  the  timeout  bit  in  their  trigger  masks.  At  transmission  tune, 
the  LPR  constructs  an  MDP  #l  packet:  the  same  packet  will  be  sent  to  all  the  momtors.  If  a  destination's 
tngger  mask  and  the  global  trigger  mask  have  at  least  one  bit  in  common  (logical  AND  is  unequal  to 
0).  the  LPR  transmits  the  MDP  #1  packet  to  that  destination.  The  packet  is  transmitted  to  an  attached 
monitor  tirst  (if  there  is  one):  the  order  of  transmissions  to  the  other  attached  and  remote  monitors  is 
random. 

If  a  request  is  received  while  the  snap-shot  buffer  is  already  in  use.  the  request  is  acknowledged  by 
SNAP,  but  the  .MDP  request  is  dropped  and  an  RCNP  is  sent  to  NACK  the  request.  The  monitor  must 
lime  out  and  request  the  MDP  again.  No  further  action  is  taken  by  the  LPR. 
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Appendix  A.  MDP  Packet  Formats 


This  Appendix  specifies  the  formats  of  MDP  packet  types  0  through  8.  Every  MDP  packet  is  a  sequence 
of  adjacent  8-bit  bytes  that  are  organized  into  fields.  Each  field  is  an  integer  number  of  bytes  that  have 
special  significance  for  higher-level  protocols.  We  present  a  top-down  view  of  all  nine  MDP  packet  types 
by  breaking  each  into  its  constituent  fields  and  e.xpiaining  the  meaning  and  purpose  of  each. 
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A..  I  The  VIDP  Packet  Header 

The  MDP  Packet  Header  consists  of  48  bits.  The  most  significant  16  bits  give  the  version  number.  MDP 
type,  packet  number,  and  the  number  of  packets  in  the  MDP  (Figrj'e  L). 

15  0 


12  3  4 

1.  Header  version  (currently  01 
MDP  type  (0  -  81 

3.  Packet  sequence  number 

4.  Number  of  packets  in  MDP 

Figure  A.  1;  MDP  Packet  Header,  first  16  bits 

The  least  significant  32  bits  of  the  header  is  the  MDP  creation  time  (in  uxuts  of  6.656  milliseconds  1 


given  by  bus  7  through  39  of  LPP. .  currer.t-time  variable  in  the  LPR  (Figure  2.). 
31  0 


Figure  A.2;  MDP  Packet  Header,  last  32  bits 
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\.l  MDP  Type  #  0  -  Radio  Request/! 'ommand  Packet 

This  packet  is  used  to  request  that  an  LPR  perform  network-control  tasks;  e.g.,  send  an  MDP  packet, 
clear  its  CUMSTATs.  etc.  This  packet  contains  the  two  fields: 

1 .  The  header 


15  0 

I  >  I  .  I  I  I  t  \  I  '  1 


Version  Reser\'ecl  sub.type 

Figure  A.3:  The  MDP  Type  0  Header  Format 

The  allowable  sub.type  field  values  are; 

«a)  SEND -MDP 
(b)  SEND-MEJ^DPl 
(C)  CLEAR.CUMST.2.T 
Id)  CANCEL-  MDPl 
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2.  The  2-byte  data  tields 

.-\Jter  the  packet  header  there  are  a  variable  number  of  2-byte  data  fields. 

,a)  [f  the  sub -type  field  ts  set  to  3END_MDP  the  2-byte  data  fields  have  the  following  special 
format; 


15  0 

1  I  I  I  I  I  I  J  II  t  I  II  I  1 


Reserved  MOP  type 

bi  If  the  sub -type  field  is  set  to  SEND_ME_MDP.l  the  data  field  has  the  following  format; 


15 

0 

i  1  <  1 

i  ;  ; 

till 

1  (  <  I  I  1  >  1  1  1  1  1 

1  t  1  1  1  1  ■  till 

1  1  <  1  1  1  ■  1  1  1  • 

t  1  t  1  1  1  •  lilt 

1  1  r  I  1  1  1  r  1  >  i 

Reserved 

Trigger  Mask 

15 

0 

1  1  1  1  1  1  '  1  1  I  > 

1  1  1  1  1  i  •  till 

1  1  I  1  1  1  I  lilt 

Mininum  Transmission  Rate 

15 

0 

(  1  1 

1  I  1 

1  1  1 

1  1  1 

t  1  1 

1  1  1  1  1  1  <  lilt 

I  1  1  1  1  1  ■  till 

1  1  I  1  1  I  '  lilt 

1  1  1  1  1  1  '  1  1  1  1 

1  1  1  I  1  I  •  1  1  1  < 

Maximum  Transmission  Rate 


11 


BBN  Systems  and  Technologies  Corporation 


Report  No.  7165 


Tricrcrer  Mask  These  12  bits  indicate  which  conditions  will  tnzger  the  transmission  ot 
MDP  #1.  The  conditions  are  coditied  as  trigger  values.  (See  Appendix  B.) 

Minimum  Inter-transmission  Time  The  minimum  number  of  seconds  between  suc¬ 
cessive  MDP  #1  transmissions.  A  value  of  zero  means  use  the  current  value,  or  if  it  has 
never  been  set  by  the  Network  Manager,  use  the  default  value  of  30  seconds. 

Maximum  Inter-transmission  Time  The  maximum  number  of  seconds  between  suc¬ 
cessive  MDP  #l  transmissions.  A  value  of  zero  means  use  the  current  value,  or  if  it  has 
never  been  set  by  the  Network  Manager,  use  the  default  value  of  1800  seconds. 

ic)  If  the  sub.type  held  is  set  to  CANCELJMPDl  the  packet  has  no  data  field. 

idi  If  the  5'ib-type  field  is  set  to  CLEAR.CUMSTAT  the  data  field  is  32-bits  long.  It  specifies 
a  protocol  time  (in  units  of  6.656  milliseconds  1  when  the  LPR  is  to  clear  all  its  CUMSTATs. 
The  value  zero  indicates  causes  the  LPR  to  clear  its  CUMSTATs  upon  receipt  of  the  packet. 
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\.l  VIDP  Type  #1  -  (ienerai  Status 

This  packet  contains  LPR  status  information.  It  contains  the  following  fields: 
1.  The  header 


15  0 

!  I  I  11  i  j  r  I  t  I  I  I  I  \ 


abed  e 

I  a)  MDP  version  number 
(b)  Reserved 

ic)  Number  of  monitors  in  the  packets  d,  2,  or  3i 
(di.  Number  of  attached  devices 
l  e)  Number  of  neighbor  LPRs 
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2.  Tngger  musks  and  transmission  timers. 


Number 


15 


Trigger  Mask 


Minimum  Inter-transmission  Time 


15 


Maximum  Inter-transmission  Time 


Number  The  number  of  triggers  that  are  set.  This  information  is  used  in  parsing  the  tngger  counter 
section.  (This  held  is  at  the  end  of  the  packet.) 

Trigger  .Mask  A  mask  of  triggers  which  have  occurred  smce  the  last  transmission  of  an  unso¬ 
licited  MDP  #1.  It  is  zero  for  solicited  (polled)  MPD  #1  packets.  See  Appendix  B  for  a  list 
of  tnggers. 

.Mi.ni.mum  Inrer-transmissron  Time  The  minimum  number  of  seconds  between  succes¬ 
sive  MDP  #1  transmissions.  A  value  of  zero  means  use  the  current  value,  or  if  it  has  never 
been  set  by  the  Network  Manager,  use  the  default  value  of  30  seconds. 

Maximum  I.-iter-transmission  Time  The  maximum  number  of  seconds  between  succes¬ 
sive  MDP  #l  transmissions.  A  value  of  zero  means  use  the  current  value,  or  if  it  has  never 
been  set  by  the  Network  Manager,  use  the  default  value  of  1800  seconds. 
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The  next  three  32-bit  tields  contain  LPR.  -OP.disC-nu.Ti.  LPR.  OS.dist.n'jim,  and  LPR.  'cc-a* 
respecuvely. 

4.  The  next  twelve  consecutive  16-bit  tields  contain  the  following  CUMSTATS  in  the  indicated  order: 

(a)  cumstat .  RTX_1 00 

(b)  cumstat  .RTX_4 00 

(c)  cumstat .  RRX-GOOD.l 00 

(d)  cumstat .  RRX.GOOD -4 00 

(e)  cumstat .  PJ^X_EAD.l 00 

(f)  cumstat  .RRX-EAD.4 00 

(g)  cumstat  .  RRX.PRC? 
ihi  cumstat  .RTX-PROP 

li)  duplicate  packet  received  counter 
!j)  total  retransmission  counter 
^k)  cumstat .  HTX-tctal 
il)' cumstat  .HRX.total. 

Items  ( i)  and  (j)  are  the  least  significant  16  bits  of  the  following  CUMSTAT  sums: 

duplicate  packet  received  counter 

cumstat  .RRX_FWD^UPJ^TXQ 
cum.stat  .RRX_FWD_D UP -FILTER  + 
turns t  at  .  RRX-D  ID  -DUP  _RTXQ  - 
cumstat  .RRX-DID-DUPJ'ILTER  - 
cumstat -RRXJDIDJDEV-DUP.TXQ 
cumstat  .RRX_DID_DEVJ}UP -FILTER 

total  retransmission  counter 

cums  t  at  .  RTX-NBR.OFF  .TXC 1  -i- 
cumstat  .RTXJfBR.OFF.TXCD  + 
cums t  at  .  RTX-NBR-OFF  -TXC3  -r 
cumstat  .RTX_NBR.OFF-TXC4 
cumstat  .RTX_NBR.OFF-TXC5  - 
cumstat  .RTX-NON.OFF.TXCl  * 
cumstat  .RTX-NON.OFF-TXC2  t 
cums  t  at .  RTX-NBR-TOS  -TXC  1  - 
cumstat  .RTXJIBR.TOS-TXC2  * 
cumstat  .RTX-NON-TOS-TXCl  + 
cumstat  .RTX_NON.TOS-TXC2 

5.  The  next  32-bit  field  is  the  time  the  protocol  came  up  in  units  of  6.656  milliseconds.  It  is  right- 
shifted  to  be  consistent  with  the  timestamp  m  the  MDP  header. 
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a  b  c  d  e  f 

(a)  Time  slot  duration  LPR.  time_s lot-duration 
(bl  LPR.hdlc-dte.dce,  DTE  =  1.  DCE  =  0 
(c)  LPR  .  rsmcte-cnt  rl-Tintr,  ON  =  [,OFF  =  0 
(dl  LPR.  auto_restart,  ON  =  1.  OFF  =  0 
(e)  LPR .  RF .power  maximum  transmitting  power 
(0  LPR.  rf_freq  LPR  frequency  setting 

5.  Two  consecutive  16-bit  tields;  the  smoothed  average  and  deviation  of  the  packet  length  (in  words, 
one  word-equals  two  bytes)  of  all  transmitted  packets.  See  Appendix  C  for  details. 

7.  A  consecutive  sequence  of  16-bit  held  pairs,  one  pair  for  each  monitor;  the  first  field  contauis 
the  monitor’s  ID,  the  second  contains  the  MDP  transmission  counter.  The  maximum  number  of 
monitors  is  3.  The  monitor  ID  is  the  ID  of  one  of  the  monitors  that  requested  the  MDP 
mdpl.tabie  .monitor. ID.  The  MDP  transmission  counter  is  the  number  of  MDP  messages 
that  have  been  sent  to  this  monitor:  mdpi.tabie  .  ID.TX.ccunter. 

8.  A  consecutive  sequence  of  16-bit  fields,  one  for  each  device.  Each  field  contains  the  device  ID. 
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A  consecutive  sequence  of  l6-bit  quintets,  one  for  each  neighbor.  Each  quintet  has  the  following 
infbrmauon: 

15  0 


— i — 1 — ,  1 

1  t  1  ■ 

till 
lilt 
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1  1  < 
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Neighbor  LPR  ID 
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b 
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e 

f 

g 

h 
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i 

(a)  nbr.t: able  .  good-neighbor 

(b)  nbr.table .  good-r;:.i00 

(c)  nbr-table .  good.r.x_400 

(d)  nbr.table .  good.tM.lCO 
le)  nbr.table  .  good-tn. 400 

lO  Is  this  neighbor’s  frequency  different  from  my  frequency?  0  =  false.  1  =  true, 
(g)  Is  this  neighbor's  time  slot  different  from  my  time  slot  ?  0  =  false.  1  =  true. 
(,h)  Is  this  neighbor  in  time  sync  with  me?  0  =  false,  1  =  true. 

(i)  The  link  receive  quality  at  100  Kbps:  nbr.table  .  rx.QJ.00 

(j)  The  link  receive  quality  at  400  Kbps:  nbr.table  .  rx_Q.4  00 
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LPR’s  AGC  Nbr’s  AGC 


N.  B.  The  last  four  counters  are  the  least-signiftcant  16  bits  of  the  respective  CUMSTATs: 

•  nexghbor.-able  . cumstat-net.tx 

•  neighbor.table .  cumstat-net.rx 

•  neighbor.cabie  .RX-AGC  This  is  the  AGC  measurement  for  the  last  PROP  from  this 
neighbor. 

•  neighbor.tabie  ,measured_AGC  This  is  the  AGC  measurement  by  the  neighbor  for  the 
last  PROP  it  received  from  this  LPR.  then  reported  in  last  PROP  from  this  neighbor. 

10.  Trigger  reports 

For  each  Trigger  there  is  a  16-bit  trigger-counter  field  that  is  the  least-significant  16  bits  of 
cumstat-ET.  The  counters  are  in  the  same  order  as  the  triggers  in  Appendix  B. 

1 1 .  Hotlist  Information 

There  is  a  single  sixteen-bit  field  that  contains  the  number  of  hotlisted  packet  radios.  For  each 
hotlisted  packet  radio  there  is  a  sixteen-bit  field  that  gives  its  ID;  its  followed  by  the  following 
sixteen-bit  field: 
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a  b  c 

I  a)  “I"  if  LPR  was  a  neighbor  when  hotlist  was  received:  “0”  otherwise, 
hi  number  of  "Request  for  Authentication”  packets  received  from  hotlisted  LPR 
c)  number  of  packets  received  from  hotlisted  LPR 

\.3  MDP  Type  #  2  -  Routing  Information 

This  packet  contains  the  following  fields: 

1 .  The  packet  header 

■ar  Version  iN umber 
(b)  Reserved 

ic)  Number  of  LPR  and  Cluster  entnes  in  packet 

(dl  Reserved 

le)  Previous  PCN  ID 

<f)  HRT  sequence  number 

ig)  Current  PCN  ID 

(hi  Reserved 

u)  Next  PCN  ID 

2.  The  following  2-byte  fields  are  included  for  each  LPR  and  each  Cluster 

(at  This  bit  is  always  set  to  ”1” 

lb)  PCN  bitmask  from  the  tier  entry 

IC)  Cluster-LPR  flag.  0  =  PR:  1=  Cluster 

(d>  Good-Bad  Tier  data  flag.  0  =  Good:  1  =  Bad; 

(e)  Destination  LPR  or  Cluster  ID 

if)  Distance  in  hops  to  the  destination  LPR 

(g)  Reporting  LPR  ED.  (The  least-significant  10  bits  of  the  ID  of  the  LPR  through  which  to 
forward  packets.) 

An  additional  16-bit  field  contains  the  attached  device  ID  for  each  device  attached  to  this  LPR. 
(The  number  can  range  between  zero  and  eight,  inclusive.) 
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\.4  MDP  Type  #  3  -  CUMSTAT  Values 

This  packet  contains  LPR  CUMSTATs.  It  contains  the  following  fields: 

1 .  The  packet  header 

(a)  MDP  #3  Header  Version 

ib)  Reserved 

ic)  Number  of  oldest  version  that  can  interpret  the  current  packet  format.  (.Later  versions  have 
just  appended  new  counters.) 

(d)  Version  number  of  current  ordering  of  CUMSTATs. 

(e)  Number  of  regular  CUMSTATs 

(f)  Number  of  Fault  CUMSTATs 

2.  A  32-bit  field  giving  the  time  since  the  CUMSTATs  were  last  cleared.  Time  is  measured  in  umts 
of  6.656  milliseconds. 
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A.5  VIDP  Type  #  4  -  Neighbor  LPR  Data 

This  packet  contains  LPR  neighbor  data.  It  has  the  following  helds: 


1 .  The  packet  header 

5  0 


a  ■  b  c  d  e 


'’a)  Version  Number 
lb)  Reserved 

(C)  Number  of  VIDP  #l  Monitors 

id)  Reserved 

ie)  Number  of  Neighbors 

2.  A  32-bit  field  that  gives  the  time  smce  the  CUMSTATs  were  last  cleared.  The  units  are  6.656 
milliseconds. 
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The  fields  are  defined  as  follows: 
ui  Reserved 

vbi  Data  rate  on  last  PROP.  1  =  400  Kbps.  0  =  100  Kbps. 

(c)  Maximum  power  output  by  this  neighbor,  nbr.table  .  RF .power 

id)  FEC  rate  on  last  received  PROP.  (The  appropriate  bit  is  taken  from  nbr.table  .  preamble.dat  a. ) 
(e)  Neighbor  ID 

(0  AGC  value  measured  by  neighbor  on  last  PROP  received  from  this  LPR.  then  reponed  in  last 
PROP  from  neighbor  neighbor.table  .  measuredJ^GC. 

I  g )  Reserved 

(h)  .Neighbor  frequency  nbr.table.  freq.chnl 
ni  FEC  error  count  nbr.t  able  .  FEC.error.count 
(jj  .Multipath  nbr.table  .  .Tiu-ttpath 
ik)  .Noise  r.br.t-.ole  .  ncaae 

1)  Signal  +  .Noise  Ratio  from  last  received  PROP  nbr.table .  Signal.plaa.ncaae 
im)  AGC  value  measured  by  LPR  on  last  PROP  received  from  neighbor  nbr.tab.e  .  r 10 
inj  Link  quality  at  100  Kbps  nbr.table  .  rx.^.l  00 
to)  Link  quality  at  400  Kbsp  nbr.table.  rx.Q.aOO 
(p)  nbr.table .  good-neighbor 
'q)  nbr.table .  good_rx_100 
(r)  nbr.table  .  good.r.x. 400 
IS)  nbr.table .  good-tx.l00 
tt)  nbr.table .  good.t:-:_400 
(u^  nbr.table .  single.ended_sync.calc 
(v)  nbr.table .  last.time.slot 

4.  Two  fields  for  each  monitor,  a  16-bit  field  that  gives  the  monitor  ID.  and  a  32-bit  field  that  gives 
ndp.table .  cumstat  J4DPs-TX. 
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MDP  Type  #  5  -  LPR  Module  Versions 

This  packet  contains  LPR  module  versions.  It  has  the  following  lields: 
1.  The  packet  header 
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Reserved 

2.  .-V  32-bit  field  that  gives  the  lOP  distnbution  number 

3.  A  32-bit  field  that  gives  the  OS  distnbution  number 

4.  .A  32-bu  field  that  gives  the  SL'RAlP  distnbution  number 

5 

0 

!  <  1  1 

i'll 

1  1  ) 

1  1  I 

1  1  1 

1  t  1 

1  1  1 

III  1  1  1  1  1 

III  1  1  1  1 
III  1  1  1  I 
III  till 

a  b 


15  0 


c  d 

5.  (a)  Protocol  stnng  length  in  bytes  (including  ETX) 

(b)  OS  string  length  in  bytes 

'c)  lOP  string  length  in  bytes 
(d)  Reserved 

6.  A  sequence  of  one-byte  Protocol  string  character  fields.  The  number  of  fields  equals  the  protocol 
length. 

7.  A  sequence  of  one-byte  OS  string  character  fields.  The  number  of  fields  equals  the  OS  length. 

8.  A  sequence  of  one-byte  lOP  string  character  fields.  The  number  of  fields  equals  the  lOP  length. 
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\.7  \IDP  Type  #  6  -  LPR  Fault  Queue 

This  packet  contains  LPR  fault  Queue  intormation.  It  has  the  following  fields: 
1 .  The  packet  header 


15  0 


— 

r— 

Version  Reserved  Status 

2.  A  32-bit  field  that  gives  the  time  since  the  fault  queue  was  last  cleared.  The  units  are  6.656 
milliseconds. 

The  following  sequence  which  is  repeated  for  each  fault: 

la) '  A  16'bit  field.  The  least  significant  eight  bits  give  the  number  of  occurrences;  the  most  signifi¬ 

cant  eight  bits  give  the  fault  number.  (The  least  significant  eight  bits  of  cutlS"  at  .  this.f  aa_ 

lb)  A  32-bit  held  the  gives  the  fault  timestamp  in  units  of  6.656  milliseconds. 

c)  A  sequence  of  L6-bit  fault  data  fields.  The  number  of  helds  is  equal  to  the  fault  length 
(currently  3). 
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V.S  MDP  Type  #  7  -  LPR  Timer  Values 

This  packet  contains  LPR  timing  values.  It  contams  the  following  helds: 

1.  The  packet  header 


15 
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Version  Reserved  Number  of  Entries 


2.  .A  32-bit  held  that  gives  the  time  since  the  CUMSTATs  were  last  cleared.  The  units  are  6.656 
milliseconds. 

3.  a  16-bit  held.  The  least  significant  eight  hits  are  the  current  version  number:  the  most-significant 
eight  bits  are  the  oldest  useful  version.  The  current  version  number  is  needed  to  determine  the 
order  of  the  timers.  The  oldest  useful  version  is  the  oldest  version  that  can  mterpret  this  packet 
t'ormat.  i  Later  versions  have  just  appended  new  timers. ) 

4.  The  following  sequence  which  is  repeated  for  each  entry: 

I  a)  A  16- bit  field  containing  the  minimum  timer  value 

ib)  A  16-bit  field  containing  the  maximum  timer  value 

ic)  A  16- bit  smoothed  average  timer  value 
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\.9  MDP  Type  #  S  -  LPR  Command  NACK 

This  packet  contains  an  LPR  Command  NACK.  It  contains  the  following  fields: 
1.  The  packet  header 


15  0 


a  b  c 

I  a)  Version 

b)  sub.type  of  MDP  #0  that  carmot  be  transmitted.  See  Secuon  1. 
ic)  .NACK  rea.son: 

0  =  MDP.IGNCRED -SNAP SHOT  The  MDP  request  was  ignored  because  the  snapshot  buifer 
was  in  use.  No  Data  included. 

1  =  MDP.IGNCRED_PKT-IN-USE  The  MDP  request  was  ignored  because  the  LPR  has  an 

outstanding  MDP  in  the  network. 

2  =  CANT.SET_MDP_DEST  Cannot  satisfy  the  MDPJffi_MDPl  request.  In  this  case  three 

16-bit  fields  will  follow  that  contain  the  LPR’s  current  monitor  IDs. 

2.  Three  l6-btt  fields  that  contain  data  when  the  NACK  reason  is  #2;  otherwise  these  fields  are  not 
included. 
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Appendix  B.  VIDP  Triggers 

This  Appendix  is  a  complete  list  of  all  MDP  triggers. 

0  =  MAX-IIMECUT  Send  an  MDP  #1  every  thirty  minutes. 

1  =  ?R_rAULT  Send  an  .MDP  #1  each  time  an  internally  detected  LPR  fault  occurs. 

Z  =  -^BR.STAT.ZHNG  Send  an  MDP  #l  each  time  a  neighbor  stams  change  occurs,  e.g..  good  to  bad. 
bad  to  good,  bad  to  erased. 

3  =  DEV.CHNG  Send  an  .MDP  #l  whenever  the  device  hst  changes. 

4  =  PARANLCHANGE  Send  an  MDP  #1  every  time  one  of  the  following  parameters  changes: 

1.  frequency 

2.  maximum  transmission  power  used  for  all  neighbors 

3.  time  slot  duration. 
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Appendix  C.  Algorithms  for  Packet-Length  Statistics 

We  use  the  following  notation: 

f  =  0,  1,2 _ The  sequence  of  measurement  indices. 

4,  =  the  current  mean  packet  length. 

P-  =  the  current  packet  length  measurement 

=  the  current  packet  length  mean  deviation  estimate. 

The  estimates  ore  computed  by  the  following  formulas: 


^c.l) 


.C.2i 
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